Motivation/summary

This PR replaces badger with pebble as the database for tail-based sampling.

// The database of choice is Pebble, which does not have TTL handling built-in,
// and we implement our own TTL handling on top of the database:
// - TTL is divided up into N parts, where N is partitionsPerTTL.
// - A database holds N + 1 + 1 partitions.
// - Every TTL/N we will discard the oldest partition, so we keep a rolling window of N+1 partitions.
// - Writes will go to the most recent partition, and we'll read across N+1 partitions

Benchmarks

TLDR: +3000% in indexed events/s, +76% intakev2 event rate, while on -75% memory usage and -44% disk usage

See comment for details.

Major design changes

• As pebble does not support TTL, this PR introduces a partitioning method to enforce TTL. TTL is handled by assigning a rotating partitioning key (not timestamp based) as database key prefix. There's also a background thread to run a "TTL GC Loop": for every TTL, the prefix of keys are rotated, and the expired prefix will be deleted and compacted. This explicit TTL handling enables precise deletion and the lifetime of an entry in the database is strictly bounded to 2*TTL. In fact, there's a knob partitionsPerTTL to adjust the available prefixes to trade between storage overhead and read amplification. e.g. partitionsPerTTL=1 keeps 2*TTL entries with 2 partition reads per key read, while partitionsPerTTL=2 keeps 1.5*TTL entries with 3 partition reads per key read.
• Not using timestamp based prefix enables TTL adjustments without data loss on EA hot reload / apm-server restart, as prefixes are fixed but TTL-truncated timestamps aren't.
• Sampling decision and events are stored separately in different pebble databases, as they have vastly different characteristics, which means the optimal pebble option would be different. Compression is enabled for events but disabled for decisions.

Other implied changes

• As TTL is enforced by deleting entries and compacting actively in the TTL GC Loop, there is no TTL validation on stored entries at read time, i.e. it is possible to run apm-server TBS, stop it, wait for 1 year, then restart apm-server, and old entries will be respected. In contrast, badger checks for expiry at read time. As trace IDs are supposed to be unique, the downside of not doing read-time TTL validation should be minimal.
• Pebble does not use a vlog like badger. In addition to the event and decision DB separation, this also requires changes in monitoring metrics structure. In the draft PR, the sum of table size, WAL size across the 2 DBs are summed and reported in sampling.tail.storage.lsm_size, while sampling.tail.storage.vlog_size is always 0. The change is not decided yet.

TODO:

• Initial benchmark numbers
• Memory usage compared to main
• TTL handling
• Storage limit handling
• Storage usage & numbers to facilitate Revisit default TBS storage size limit sampling.tail.storage_limit and storage limit handling #14933
• Measure sampling decision miss perf hit
• check if possible to upgrade to pebble v2.0.0: v2 module incorrectly named cockroachdb/pebble#4271
• Check for memory leak by running it for a long time, as pebble does manual memory management
• event loss on upgrade: see Migration path from badger to pebble #15423

Useful but not necessary, out of scope of this PR:

• support tbs in testing/infra/terraform/modules/standalone_apm_server for reproducible benchmark with moxy and without using ESS: terraform: support TBS in standalone_apm_server #15337

Checklist

• Update CHANGELOG.asciidoc
• Documentation has been updated

For functional changes, consider:

• Is it observable through the addition of either logging or metrics?
• Is its use being published in telemetry to enable product improvement?
• Have system tests been added to avoid regression?

How to test these changes

Enable TBS, try various sampling policies, send events, keep it running for over 2 * TTL, ensure that disk usage is bounded, and memory usage is expected.

Related issues

Fixes #15246